Peer to peer email based financial transactions

ABSTRACT

A method for peer-to-peer e-commerce transaction between a first user and a second user that is facilitated by a payment server is disclosed. The method including receiving a money request from a first user, wherein the money request identifies a second user from which money is requested. The method further including transmitting a money request email message to the second user, wherein the money request email includes a token and receiving a response email message to the money request email message, wherein the response email message includes the token. The method further including determining whether the second user is a member based on the received token and an email address associated with the response email message.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. patent application Ser. No.14/216,256 filed Mar. 17, 2014, which claims the benefit of U.S.provisional application No. 61/794,675, filed on Mar. 15, 2013, whichare incorporated by reference as if fully set forth.

FIELD OF INVENTION

The present invention is related to electronic payment systems.

BACKGROUND

Some email-based payment methods require cumbersome web-basedauthentication processes to complete a transaction. This requires theuser to have an active internet connection or the transaction maytypically not be completed. As mobile devices are used for a greaterpercentage of online transactions, this may present a problem sincemobile or wireless internet access may be less reliable than wiredaccess. Many users have their applications and accounts attached to morethan one device. Current electronic payment systems may be cumbersomewhen utilized on mobile devices. There is a need for a method for makingtransactions that may be easily shared on devices from desktop, laptop,tablet, smartphone and mobile phones. Email is the perennial applicationthat is shared and is the assumption of most of these devices. Virtuallyevery online application requires an email address as the basis forsigning up.

Individuals that need to collect money from large groups of people needa tool that is fast and easy to use and is designed for thenonprofessional. Small organizations, community groups, churches andfamilies may not have the capacity to make a website with a paymentpage. These types of organizations may require an accessible tool forcollecting and sending money. Many of these groups already organizecommunication through group email lists. A tool that enables the sendingof a single email message to multiple users requesting payment may be aconvenience. The capacity to request or send money from multiplerecipients may be welcomed in the marketplace.

The driver of online monetary transactions is businesses collectingmoney from individual customers. Most individual customers have paymentaccounts with businesses that allow for transactions to happen in anexpedited manner. These transactions are either a one-time transactionor an on-going registration. Although many businesses allow customers toregister accounts and submit payments these accounts only allow for thetransfer of funds in a single direction. They do not allow the customerto accept money and this is a logical outcome based on a perspectivethat the vendor provides the payment service. A vast population ofonline consumers register to pay money but not to receive money becauseit is a convenience provided by the vendor. As an alternative if thepayment tool is provided by the customer and the network to which theyare associated with new functional possibilities arise. Systems likePayPal integrate across vendors. However all of these methods aredependent on making payments on URL pages. In order to do any of theseprocesses the users must already have an email account. As a number ofregistered email based transactions grow the integration of those usersinto a single connected network may be desired. Giving individualmembers the same abilities as the vendor may be desired.

There are numerous ways to send money and receive money throughelectronic messaging. PayPal and Western Union are examples of how tosend money directly to an individual's bank account. In all of thesesystems there are inherent distinctions between businesses andindividual users. How a user may interface with a business may vary fromhow individuals correspond with each other. Although all of thesesystems may utilize email messages to send receipts and status updates,they use URLs in order to submit the transaction. Organizing a socialnetwork of users based on their email accounts may be welcome in themarket place. Designing a system where monetary transactions may beperformed by email and a user receives updates on payment requests mayeliminate the complicated setups and plugins that are required onweb-based transactions. This web-based transaction may be replaced by aone-time sign up and the capacity to request payments with no fee and nointegration of systems. Password secured email accounts may serve anadditional function as a secure site to approve transactions eliminatingredundant login information.

In an effort to expedite checkout many vendors may try and register anindividual as a customer and store credit card information and deliveryinstructions so as to allow the user to skip many cumbersome steps. Theymay also use other plugins on the checkout page where the customer isalready registered with a payment service. Both nonprofits andbusinesses promote their organizations through email advertisingcampaigns. Many customers also receive updates and invoices throughemail but are ultimately driven to web URLs to complete transactions.Businesses and nonprofits may benefit from an payment service that mayallow customers to respond directly to an offer by sending the emailwith no need for a username or password. This may eliminate steps in theprocess of purchasing or donating. Being able to identify users withthis ability may be to an organization's advantage in the marketplace.At the same time, it allows the customer to share the offer within thatpayment network. Vendors and nonprofits may welcome the new customerbase that has access to the email payment gateway and create offers thatincentivize the sharing and promotion of those deals with the communityof the email payment gateway.

Sending money to a daughter in college, collecting money for a baseballteam, buying clothes on target.com and paying rent all representdifferent levels of sending money. Each of them has a different way ofmaking the payment. A payment method that may unify all of these methodsinto a single field in which all of the actors may participate in anetwork may be ideal. Although participation in many social networksvary and many automated payment systems limit their vendors, virtuallyall of these actors have email accounts as a given of online life.Forming a network of users that is based in an email payment system andthat exploits the social interactions may be welcome in the marketplace. An email based financial transaction for individuals to send andreceive money is the next logical step.

SUMMARY

The system described herein may comprise a network that allowsregistered individual customers to make financial transactions usingemail payment gateway. Registered individuals and organizations may sendand receive payments from other members within the network withcredit/debit cards and bank account information. Payments may be made byresponding to emails. This network permits individuals and organizationsto register and use the email payment gateway through online sign upwithout the need for a business to business integration. This allowsboth the sending and receiving of money to any member in the network. Italso allows registered users to send a group email with the capacity forall of those recipients to pay them in email based responses. Thisallows for a similar functionality as email campaign management systemslike MAILCHIMP or CONSTANT CONTACT but with the ability to dotransactions built in. In this embodiment the email payment technologymay take on aspects of social networking allowing for profile and publicpay pages that may let campaigns and offers go viral. An offer from avendor or individual may travel the network by virtue of the community'ssocial interactions.

A method for peer-to-peer e-commerce transaction between a first userand a second user that is facilitated by a payment server is disclosed.The method including receiving a money request from a first user,wherein the money request identifies a second user from which money isrequested. The method further including transmitting a money requestemail message to the second user, wherein the money request emailincludes a token and receiving a response email message to the moneyrequest email message, wherein the response email message includes thetoken. The method further including determining whether the second useris a member based on the received token and an email address associatedwith the response email message.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding may be had from the following description,given by way of example in conjunction with the accompanying drawingswherein:

FIG. 1 shows an example of a block diagram for a system for peer to peeremail based financial transactions;

FIG. 2 is a flow diagram for a peer to peer money request and sign upusing an URL-Targeted Token;

FIG. 3 is a transactional flow diagram for a method for requesting moneyfrom an unregistered responder using an URL-Targeted Token;

FIG. 4 is a transactional flow diagram for a method for requesting moneyfrom a registered responding member using an URL-Targeted Token;

FIG. 5 is a transactional flow diagram for a method for sending moneyfor a registered responding member using an email-targeted token;

FIG. 6 is a transactional flow diagram for a method for sending moneyfor a unregistered responding member using an email-targeted token;

FIG. 7 is an example web page for signing up with the payment server140;

FIG. 8 shows an example web page for accessing the quick send feature;

FIG. 9 shows an example web page for viewing the email blaster preview;

FIG. 10 shows an example web page for viewing a user dashboard, where amember may see the status of campaigns;

FIG. 11 shows an example web page for accessing a user's pay page;

FIG. 12 shows an example web page for a generating quick request;

FIG. 13 shows an example web page for accessing a user's accountsettings;

FIGS. 14A-14C show an example web page 1400 for generating an emailblast; and

FIG. 15 shows an example web page for an embodiment where the paymentserver is integrated with an email server.

DETAILED DESCRIPTION

When used herein, the term “token” may refer a string or file used toauthenticate a transaction. A token may be one or multiple encryptedstrings, files, passwords, cyphers or other data which may containinformation used to perform or authenticate a transaction when sent topayment servers. These tokens may be encrypted using a public-privatekey encryption system. The vendor or a party with knowledge of thevendor's private key may generate an encrypted token. Alternatively, apayment system or e-commerce site may generate this token on behalf ofthe vendor.

When used herein, the term “member” may refer to a person that is aregistered with an account.

When used herein, the term “individual” may refer to people that areonline.

When used herein, the term “initiator” may refer to a member that startsa transaction by contacting one or more recipients.

When used herein, the term “responder” may refer to a recipient thatresponds to a communication from an initiator regarding the transaction.

When used herein, the term “transaction request” may refer to a generalterm for receiving money or sending money.

When used herein, the term “email-targeted token” may refer to a tokenassociated with a specific email address.

When used herein, the term “URL-targeted token” may refer to token notassociated with a specific email address and that may be forwarded andused by other members.

When used herein, the term “pay page” may refer to a publicly accessibleweb page where individuals may make payments to members.

Disclosed herein are processor-executable methods, computing systems,and related technologies for peer to peer email based financialtransactions. While the technologies described herein are discussedusing e-mail as an example, they may also be applicable to similarcommunication mediums, such as SMS and MMS communication channels.

The peer to peer system described herein allows the payment server 140to allow individual members the same ability to collect money as well aspay vendors. Members may quickly send each other money with minimuminformation. Members get a publicly accessible web page for receivingpayments. Members may send their own email campaigns with the ability tosend and collect money. Members may socialize and share offers.

As described hereinafter in greater detail, the system described hereinallows a user to create a profile that has a public pay page. A user maygenerate a quick request for money in its simplest form with only twoinput fields. This user may be a member that is registered with ane-commerce website. A user may generate a quick send message to sendmoney in its simplest form with only two input fields. A user may use anemail blaster feature to design and send an email requesting money withmultiple amounts, graphics, and buttons to one or multiple individuals.When a request to send out an email blast is received, the system maygenerate a type of email for members and a different type of email fornon-members. A user may respond to other solicitations. For example, ifthe user is a member, they may respond directly using an email messageand may not need to login whereas a nonmember user may be directed to anURL which asks them to register and/or login. A user may maintain emailaddress book and email campaigns. A user may monitor email campaignresponses. A user may schedule payments and reminders. A user mayschedule email reminders to themselves with response mailto hyperlinksthat let the user maintain the account from email. A user may select aninterface that adapts the system to being more geared to a payroll orinvoicing system. The system may be configured for competitive biddingor limited time offers that monitor quantities or expiration dates thatmembers respond to as individuals or as communities.

FIG. 1 shows an example system 100 that may be utilized for e-commercefinancial transactions. The example system 100 includes multiplecustomer devices 150 and 156, a payment server 140 that may beoperatively connected to a peer to peer unit 130, multiple customer bankaccounts 190 and 191, a bank/escrow server 180 and a payment processingsystem 181, each of which may communicate over one or more wired and/orwireless networks. The wired or wireless networks may be public, privateor a combination of public or private networks.

The customer devices 150 and 156 may be, for example, a cellular phone,a smartphone, a desktop computer, a laptop computer, a tablet computer,or any other appropriate computing device. As shown in FIG. 1, thecustomer device 150 that is associated with customer A includes aprocessor 151, memory 152, a communications unit 153, a display unit 154and web browser unit 155, which may communicate data to/from the webserver module(s) in the vendor server 120 and payment server 140. Theweb browser unit 155 may include and/or communicate with one or moresub-modules that perform functionality such as rendering HTML (includingbut not limited to HTML5), rendering raster and/or vector graphics,executing JAVASCRIPT, and/or rendering multimedia content. While notshown in FIG. 1, the customer device 156 associated with customer B maycontain the same or similar components.

Alternatively or additionally, the web browser unit 155 may implementRich Internet Application (RIA) and/or multimedia technologies such asADOBE FLASH and/or other technologies compatible with Internet basedcommunications. The web browser unit 155 may implement RIA and/ormultimedia technologies using one or web browser plug-in modules (e.g.,ADOBE FLASH), and/or using one or more sub-modules within the webbrowser unit 155 itself. The web browser unit 155 may display data onone or more display devices (not depicted) that are included in orconnected to the customer device 150, such as a liquid crystal display(LCD) display or monitor. The customer device 150 may receive input fromthe user of the customer device 150 from input devices (not depicted)that are included in, or connected to, the customer device 150, such asa keyboard, a mouse, a microphone or a touch screen, and provide datathat indicates the input to the web browser unit 155.

The payment server 140 may include an HTTP server module 141, a tokengenerator 142, a processor 143, memory 144, a token decoder 145, anorder execution module 146, a DB module 147, a message processing module148, and an interface module 149.

The HTTP server module 141 provides a website that may be accessed by acustomer device 150. The HTTP server module 141 may implement the HTTPprotocol, and may communicate Hypertext Markup Language (HTML) pages andrelated data from the website to/from the customer device 150 usingHTTP. The vendor server 120 may be connected to one or more private orpublic networks (such as the Internet), via which the HTTP server module141 communicates with devices such as the customer device 150. The HTTPserver module 141 may generate one or more web pages and may communicatethe web pages to the customer device 150, and may receive responsiveinformation from the customer device 150.

The HTTP server module 141 may be, for example, an APACHE HTTP server, aSUN-ONE Web Server, a MICROSOFT INTERNET Information Services (IIS)server, and/or may be based on any other appropriate HTTP servertechnology. The payment server 140 may also include one or moreadditional components or modules (not depicted), such as one or moreload balancers, firewall devices, routers, switches, and devices thathandle power backup and data redundancy.

The token generator 142 may generate tokens for use in e-commercetransactions. Tokens may be encrypted strings which contain informationto perform transactions. A token may be one or multiple encryptedstrings, files, passwords, cyphers or other data which may containinformation used to perform or authenticate a transaction. A token mayinclude one or more of the following parameters or other parameters notlisted below:

-   -   a) private-key: The private key provided by the payment server        140.    -   b) public-key: Payment server's 140 public key, provided by the        payment server 140.    -   c) partner-id: The partner ID given provided by the payment        server.    -   d) environment: The environment the vendor wants to generate        buttons for. This distinguishes whether the token is being used        in a testing environment or in the live environment (and running        real transactions).    -   e) config: The path to a configuration file in yml format. This        may hold a default set of information, e.g., private_key,        public_key, partner_id, and other information—so they don't have        to be entered separately each time a token is generated. The        configure field may also contain information specific to an        offer (e.g. dollar amount) or a customer (e.g., card token) if        multiple tokens are being generated with similar components.    -   f) type: The type of token to generate (site, email, universal).        There are multiple types of tokens that a token generator may        generate and decode. For example, site tokens may be used for        website transactions, email tokens for two-click email payments,        and universal tokens for email validations.    -   g) card: The card token associated with the recipient of this        token. When a customer is registered with the payment server        140, the vendor receives a credit card token—a unique identifier        that references the specific card associated with that customer        and vendor. When the vendor is generating a token to submit to        payment server 140, they may include the card token as a        customer identifier.    -   h) email: The email associated with the receipt of this token.    -   i) URL: The Signup URL the recipient should go to if customer        doesn't have payment information registered with payment server        140.    -   j) amount: The amount a user should be charged for the        transaction the token is generated for.    -   k) user-data: Data to pass back as a reference. This data may        include custom data that the vendor may want to pass through the        payment server 140 and receive back when a transaction has        completed. It may include an item reference number or SKU,        customer address, or other piece of data that is not required by        payment server 140 to complete a transaction, but that the        vendor wants associated with that transaction.    -   l) expires: Expiration date for token, integer value of seconds        since epoch.    -   m) header-user-agent: The HTTP_USER_AGENT from the request        header. HTTP headers are sent as part of a request from a        customer's web browser unit 155 for a piece of information.        These headers define the parameters that the web browser unit        155 is expecting to get back. The user-agent is the identifier        of the software that is submitting the request—typically the        identifier of the web browser unit 155 that is requesting the        content.    -   n) header-accept-language: The HTTP_ACCEPT_LANGUAGE from the        request header. The accept-language is the acceptable language        for the response—e.g. the language in which the web browser unit        155 is requesting the content be sent back.    -   o) header-accept-charset: The HTTP_ACCEPT_CHARSET from the        request header. The accept-charset is the character sets that        are acceptable for the response—e.g. the character set in which        the web browser unit 155 is requesting the content be sent back.    -   p) ip-address: The IP address of the token recipient.

To confirm an e-commerce transaction via email, the customer sends anemail embedded with a token to the payment server's 140 address. Thesystem 100 is designed to allow the vendor flexibility to offer dealsfor a limited time or number or responsive to available inventory. Forexample, the token may be configured to expire by default after twoweeks, or any predetermined time, or never expire.

The memory 144 may be configured to store information associated withe-commerce transactions. This may include inventory information,information used to generate web pages, customer information, and othere-commerce data.

The payment server 140 may also be in communication with the peer topeer (P2P) unit 130. The P2P unit 130 may comprise an offer creationunit 131 and an account management unit 132, and as described in greaterdetail hereafter, may facilitate P2P transactions.

The customer bank accounts 190 and 191 may be controlled by a thirdparty system bank. The payment server 140 may communicate with thecustomer bank accounts 190 and 191 to verify that the customer hasadequate funds or credit for the requested purchase. For example, thecustomer bank accounts 190 and 191 may be a controlled by VISA, AMERICANEXPRESS, MASTERCARD or any other bank or banking or financial networkthat a customer may use for online payment. The customer bank accounts190 and 191 may be a server for virtual currencies, such as BITCOIN,etc. While not shown in FIG. 1, customer bank accounts 190 and 191 maycomprise a processor, memory, a communications unit, and networkinterface.

The system 100 may also comprise a bank/escrow server 180 to store fundsin escrow during transactions. While not shown in FIG. 1, bank/escrowserver 180 may comprise a processor, memory, a communications unit, andnetwork interface. The bank/escrow server 180 may serve to serve as athird party holding location on behalf of transacting parties.

A payment processing system 181 may serve to facilitate transactions byperforming payment processing duties. While not shown in FIG. 1, paymentprocessing system 181 may comprise a processor, memory, a communicationsunit, and network interface.

As examples described below may use different types of tokens, anemail-targeted token and URL-targeted (or shareable) tokens. These twoare selected as examples, but other tokens may be used.

For email-target tokens, an initiator using a customer device 150 maycompose an email request and add a list of recipients. When theinitiator sends the email, the payment server 140 may determine whichrecipients are registered with payment server 140 and which are not. Thepayment server 140 may send two separate emails—one to members and oneto non-members. The members get an email checkout with mailto hyperlinksand the non-members get a link to the URL pay page and a sign up. Themailto hyperlinks sent to members may contain a token for processing atwo-click email checkout. The token may comprise an embedded identifierof the email address of the recipient (that is the intended responder),along with the other necessary information required to complete thetransaction. The intended recipient/responder may send a response email,using e.g. customer device 156, to the payment server 140. If theresponse email contains the token, the payment server 140 decodes thetoken, confirms that the embedded email address matches the address thetoken was submitted from, and, assuming all checks pass, the paymentserver 140 processes the transaction. If an individual other than theintended recipient/responder returns the token to the payment server140, the process may fail when the email address contained in the tokenis compared to the submitting email address. This individual may receivean error notification instructing them to complete their purchase byclicking on URL to a payment page on which they may fill out theirpayment information and simultaneously register for an account with thepayment server 140.

For URL-targeted tokens (i.e. sharable tokens) the initiator, using acustomer device 150, may compose an email request and adds the list ofrecipients. When the initiator sends the email campaign, the paymentserver 140 sends out an identical email to each recipient. Within thisemail is a mailto hyperlink, which contains a token for processing atwo-click email checkout. This token contains necessary informationrequired to complete the transaction, but it may not contain anyidentifier of the intended recipient/responder. If a member responds tothe campaign, the payment server 140 recognizes the email address thatis in the submitted email message (not in the token), reads the contentof the token, and (if all other checks pass) processes the transaction.If the response is from a nonmember, the payment server 140 responds bysending an email with a URL link to the pay page of the initiator of therequest. At that point the nonmember enters their payment informationand completes the transaction.

URL-targeted tokens may be forwarded between individuals, it may be usedby any member, and there is a built-in path for nonmembers to bedirected to a URL at which they may complete a transaction.

In some embodiments, sending money may be processed differently thanrequesting money in regards to which token type is used. This may be forsecurity reasons. For example, in sending money, the token used may bethe email-targeted token. Whereas in requesting money, theemail-targeted token and/or the URL-targeted token may be used.

FIG. 2 is a flow diagram for a method 200 for a peer to peer moneyrequest and sign up using an URL-Targeted Token. An initiator generatesan email with a token and send the email to the responder (step 202). Inthis scenario, the initiator may be using customer device 150 and thetoken may be embedded in a mailto hyperlink in the email message. Theemail is received by the responder, e.g., using customer device 156(step 204). The responder, using customer device 156 may then click onthe mailto hyperlink (step 206). The payment server 140 may receive thisemail message and determine whether the responder is a registered memberor an unregistered member. If the users are registered members, thepayment server 140 is able to decode the token, look up the memberidentification information, perform security checks, and process thetransaction (208). Once the transaction is processed, the payment server140 may then update the accounts for the initiator and responder andsend email confirmations to both parties (210). If the responder is anunregistered member, the payment server 140 may still be configured todecode the token and perform a look up of member identificationinformation (step 212). However, because the member identificationlookup failed, the payment server 140 generates an email with a web pagelink to the initiators pay page (step 214). The payment server 140 sendsan email to the unregistered nonmember; this email includes a link tocomplete the transaction and signup on a web page (step 216). The usermay select the hyperlink embedded in the email; enter paymentinformation along with additional registration fields allowing thepayment server 140 to verify the information. The transaction issubmitted for processing and the information regarding the user isstored (step 218). The payment server 140 updates the initiator andresponder accounts and sends confirmation emails to both parties (step220).

FIG. 3 is a transactional flow diagram for a method for requesting moneyfrom an unregistered responding user using URL-Targeted Token. In thisexample, a money request is generated from member A′s account 302 whichis sent to an e-commerce system 305 (step 310). Typically, this may beperformed by a member accessing the account using a customer device 150.The e-commerce system 305 generates a token (step 311). The e-commercesystem 305 sends the money request including the token to an emailaccount 304 associated with member B (step 312). Member B, usingcustomer device 156 sends a response email including a token to thee-commerce system 305 (step 313). As shown in FIG. 3, the e-commercesystem 305 may decode the token and not recognize the address (step314). In response, the e-commerce system 305 send an email including anURL pay link to an email account associated with member B (step 315). Byselecting the URL pay link, member B is directed to a web pageassociated with member A (step 316). Member B, using e.g. customerdevice 156 may submit payment information and register with the paymentserver 140 from member A's web page 301 (step 316). The e-commercesystem 305 receives this information, processes the payment andregisters the user as a member (step 318). The e-commerce system 305sends notifications of a successful transaction to member A and member Bvia their email accounts 302 and 304 (step 319). The e-commerce system305 may then transfer funds into member A's bank account 303 (step 320).Payment server 140 may be an example of an e-commerce system 305 as usedherein.

FIG. 4 is a transactional flow diagram for a method for requesting moneyfrom a registered responding member using an URL-Targeted Token. In thisexample, a money request is generated from member A's account 302 whichis sent to an e-commerce system 305 (step 410). Typically, this may beperformed by a member accessing the account using a customer device 150.The e-commerce system 305 generates a token (step 411). The e-commercesystem 305 sends the money request including the token to an emailaccount 304 associated with member B (step 412). Member B, usingcustomer device 156 sends a response email including a token to thee-commerce system 305 (step 413). The e-commerce system 305 decodes thetoken and the transaction is processed. The e-commerce system 305 sendsnotifications of a successful transaction to member A and member B viatheir email accounts 302 and 304 (step 415). The e-commerce system 305may then transfer funds into member A's bank account 303 (step 416).

FIG. 5 is a transactional flow diagram for a method for sending moneyfor a registered responding member using an email-targeted token. Inthis example, a money request is generated from member A's account 302for multiple recipients which is sent to an e-commerce system 305 (step510). Typically, this may be performed by a member accessing the accountusing a customer device 150.

The e-commerce system 305 receives the message and determines which ofthe multiple recipients are registered and unregistered users (step511). The e-commerce system 305 sends a money message with a token to anemail account associated with member B (step 512). Member B, using acustomer device 156 may accept the money message and send a response viaemail with an embedded token (step 513). The e-commerce system 305 mayreceive the email message, decode the token, match the email addresswith an email address associated with a member and process thetransaction (step 514). The e-commerce system 305 sends notifications ofa successful transaction to member A and member B via their emailaccounts 302 and 304 (step 515). The e-commerce system 305 may thentransfer funds into member B′s bank account 306 (step 516).

FIG. 6 is a transactional flow diagram for a method for sending moneyfor an unregistered responding individual using an email-targeted token.In this example, a money request is generated from member A's account302 for multiple recipients which is sent to an e-commerce system 305(step 610). Typically, this may be performed by a member accessing theaccount using a customer device 150. The e-commerce system 305 receivesthe message and determines which of the multiple recipients areregistered and unregistered users and the email may be determined to befrom an unregistered user (step 611). The e-commerce system 305 sends amessage with an URL link to an email account associated with member B(step 612). Member B, using a customer device 156 may visit a signuppage and create an account with the e-commerce system 305 (step 613).The e-commerce system 305 may accept payment from A, once the recipientis registered (step 614). The e-commerce system 305 may process memberA′s payment (step 615). The e-commerce system 305 sends notifications ofa successful transaction to member A and member B via their emailaccounts 302 and 304 (step 616). The e-commerce system 305 may thentransfer funds into member B's bank account 306 (step 616).

FIGS. 7-13 show example web pages that may be displayed by a web browserunit associated with a customer device 150 or 156. As will be describedin detail below, the web pages may include display elements which allowinitiators and responders to complete peer to peer email based financialtransactions utilizing one or more emails. The web pages may be includedin a web browser window that is displayed and managed by the web browserunit 155. The web pages may include data received by the web browserunit 155 from the payment server 140. The web pages may include paymenttransaction information.

The web browser window may include a control area 700 that includes aback button 702, forward button 703, refresh button 704, home button705, and address field 706. The control area 700 may also include one ormore additional control elements, such as bookmark page etc. Aninitiator or responder using a customer device 150 or 156 may select thecontrol elements in the control area 700. The selection may beperformed, for example, by clicking a mouse or providing input viakeyboard, touch screen, and/or other type of input device. When one ofthe control elements is selected, the web browser unit 155 may performan action that corresponds to the selected element. For example, whenthe refresh button 704 is selected, the web browser unit 155 may refreshthe page currently viewed in the web browser window.

FIG. 7 is an example web page 710 for signing up with the payment server140. A user registers online with the payment server 140 to send andreceive payments using email messaging. The user visits or is directedto the payment server 140 web page 710 if they are not alreadyregistered they set up an account. As shown in FIG. 7, the web page mayinclude multiple input fields 712-724. A user wishing to become a memberand use the peer to peer payment features may be directed to the sign upweb page 710. A user may access the web page 710 using a customer device150 or 156, such as a laptop, smartphone, tablet, or other computer. Afirst time user of the peer to peer system may be taken to the sign upweb page 710 if an unrecognized email address is submitted from a peeror an email is received from an unrecognized address. As the customerdevice 150 or 156 receives input for the input fields 712-724, the webbrowser unit 155 may store one or more data structures that reflect theselections made in the input fields. As shown in FIG. 7, the inputfields 712-720 may comprise a first name field, a last name field, anemail address field, a create password field and a repeat passwordfield. Input field 722 as shown in FIG. 7 is a sign up button, to beselected by the user once input fields 712-720 are filled out. Inputfield 724 is a button to notify the payment server 140 that the newaccount is for a business user. Selecting input field 724 may take auser to another sign up web page with different input fields. Further,as the selections are updated, the web browser unit 155 may update theweb page 710 to indicate additional, or more specific, questions thatmay be associated with the selections.

While not shown in FIG. 7, the user may also be prompted to providecredit card and bank account information or they may wait until theywish to retrieve funds. They user may also setup a profile page thatincludes a description of themselves and an avatar.

Once an individual is a member they are able to begin sending orreceiving payments. Assuming they are logged into their member account,they may send email transaction requests to other individuals. A membermay send a transaction request to one or many email addresses and thoseemail addresses are stored in the profile page. A transaction requestmay be asking for money or sending money. When logged in their accountthe member may compose the content of the transaction request email anddetermine the email list of recipients. The email is sent from there. Inthe original design, the system sent an email message containing thedetails of the request, instructions on how to complete the transactionand at least one mailto hyperlink associated with the transaction amountto registered members or a URL link to a pay page for unregisteredindividuals. With the URL Targeted Token, all users may receive a mailtohyperlink for generating a response email.

FIG. 8 shows an example web page 810 for the quick send feature. Thequick send feature allows users to send a one-off payment to otherindividuals. As shown in FIG. 8, the web page 810 may include multipleinput fields 812-818. An initiator, operating a customer device 150 mayenter an email address in input field 812 and a payment amount in inputfield 814. Input field 816 allows for an optional message to therecipient. The payment server 140 generates an email message addressedto the email address entered in input field 812 notifying them that theinitiator wishes to send them money. If the recipient is a registeredmember of the payment server 140, the email contains a button enabledwith two-click ability to accept a payment. An example of this procedureis shown in FIG. 5, above. If the recipient is not a registered memberof the payment server 140, the payment server 140 generates an emailcontaining a button with a link to sign up for an account and accept thepayment, as shown in FIG. 6, above.

FIG. 9 shows an example web page 910 for the email blaster preview. Theemail blaster feature allows a user to configure and send email blaststo multiple users with multiple buttons. These email blasts may be usedto send and receive payments. FIG. 9 shows a preview of an email thatmay be sent out using the peer to peer system described herein. As isshown in FIG. 9, the email generated may have multiple input fields912-916, each of the input fields serve as pay buttons with differentamounts. The flexibility of the email blaster allows a user to selectthe subject line, the from field, add images, include multiple paybuttons with different dollar amounts and send to larger groups.

FIG. 10 shows an example web page 1010 for a dashboard, where a membermay see the status of campaigns. As shown in FIG. 10, the web page 1010may include multiple input fields 1012-1032. If the user is using thepayment server 140 for fundraising, the user may select input field 1012to update information regarding the organization for which thefundraising is occurring. The dashboard web page 1010 also providesinput fields 1014-1018 that allow the user to visit their pay page, edittheir pay page or share their pay page by email. To create an emailblast, (e.g. shown in FIG. 9) the user may select input field 1020 tocustomize an email and mailing list for the blast. To monitor paymentreceived history, the user may select input field 1022. To monitorpayment made history, the user may select input field 1024. The user mayedit their own account by selecting input field 1026. The user mayupdate their bank information by selecting input field 1030. Further, asthe selections are updated, the web browser unit 155 may update the webpage 1010 to indicate additional, or more specific, questions that maybe associated with the selections.

FIG. 11 shows an example web page 1110 for a public pay page associatedwith a user. Once the individual has registered as a member of thepayment server 140 and has set up a profile the payment server 140generates a public pay page that may be customized by the user. A userof a customer device 150 or 156 or other customer devices may accessthis web page 1110. As shown in FIG. 11, the web page 1110 may includemultiple input fields 1112-1142. In this particular example, a user islogged in and viewing their own web page 1110. Because the user isviewing their own page, input fields 1112 and 1114 offer the user toedit the page and share the page via email, for a user not viewing theirown page, these fields may not be presented. Input fields 1116-1142allow a person to send money to the user associated with the pay page.Input fields 1116-1132 solicit a first name, last name, email address,billing address, city, state, zip code, country, and phone number of thesender. Input fields 1134 and 1136 solicit a payment amount and messageto be sent. Input fields 1138-1142 solicit payment information for thepayment identified in input field 1134. A similar page may be shown toallow the user associated with the page to send payments to otherindividuals. Further, as the selections are updated, the web browserunit 155 may update the web page 1110 to indicate additional, or morespecific, questions that may be associated with the selections.

FIG. 12 shows an example web page 1210 for a quick request feature. Thequick request feature allows a member to request a payment from anotherindividual using the payment server 140 by filling out input fields1212-1216. A user enters an email address in input field 1214 associatedwith the person from whom money is requested; a desired payment amountin input field 1212; and an optional message 1216. The payment server140 generates an email message that is sent to the email addressidentified in input field 1214. The email message may include atwo-click link or URL to pay page depending on the status of therecipient. If the recipient has a member account, that individual gets atwo-click enabled email and the transaction may be performed accordingto the example process shown in FIG. 4. When user selects send on mailtoemail, the transaction is processed. If the recipient is a non-member,the email generated comprises a link to pay page to complete payment,according to the process shown in FIG. 3.

FIG. 13 shows an example web page 1310 for accessing a user's accountsettings. As shown in FIG. 13, the web page 1310 may include multipleinput fields 1312-1334. Once a user has registered, the account settingsweb page 1310 is available to enter/update information associated withthe user. Input fields 1312-1318 request basic information such as firstname, last name, telephone, and a primary email address. Recognizingthat a user may want to use multiple emails, input emails 1320-1324allow a user to enter additional registered email addresses. In oneembodiment, each registered address may be assigned to different paymentoptions. Input fields 1326-1330 allow a user to change a passwordassociated with the account. Input field 1332 allows a user to select anavatar (i.e. an image) to be displayed with the user's pay page. Inputfield 1334 solicits a user to enter organizational details, in case theaccount is associated with an organization. Further, as the selectionsare updated, the web browser unit 155 may update the web page 1310 toindicate additional, or more specific, questions that may be associatedwith the selections.

FIGS. 14A-14C show an example web page 1400 for generating an emailblast. As shown in FIGS. 14A-14C, the web page 1400 may include multipleinput fields 1402-1428. A member may access the email blaster feature.As shown in FIG. 14A, web page 1400 includes questions to solicit amember to enter information to create an email blast. Input fields1402-1406 solicit a member, using a customer device 150, to enter sendername, subject line, and message headline information, to be used togenerate email messages. Input field 1408 allows a member to enterpayment amounts to be available in the blast. As shown in FIG. 14A,three payment amounts may be input, however, the web page 1400 may beupdated as a member enters values to allow more. The amounts entered ininput field 1408 may be converted into html buttons with embeddedtokens, allowing the recipients to pay using the two-click process.Input field 1410 solicits a user to enter a picture into the email.Input field 1412 solicits a user to enter a message body for the emailmessage that is to be generated.

As shown in FIG. 14B, once the member has input the contents of theemail message to be generated, the member may select recipients of theemail message. Input area 1414-1418 allows a member to select all users,selected users or none. If the user selects input field 1416 to send theemail message to selected users, the member may select the specificusers from the list shown in input field 1420. The member may alsomanually enter email addresses using input field 1422. Web page 1400 mayalso be configured to work with mail merge features allowing the memberto upload a formatted list of email addresses.

As shown in FIG. 14C, once the member has input the email messageinformation and selected the recipients, the member can preview thegenerated email message. A member may enter an email address in inputfield 1424 and select input field 1426 to preview the email message byemail. Alternatively, the member may preview the email via a web pagesuch as the web page shown in FIG. 9. Finally, if the member is ready totransmit the email message, the member may select input field 1428 andthe payment server 140 may transmit the email message blast to theselected recipients. While FIGS. 14A-14C show a particular configurationof input fields, as the selections are updated, the web browser unit 155may update the web page 1400 to indicate additional, or more specific,questions that may be associated with the selections.

While the examples described herein show a customer device 150 accessingthe e-commerce features using a web browser, it should be understoodthat this is just one example. The methods described herein may beperformed by different types of customer devices 150 such as a mobilephone, tablet, personal computer etc. The customer device 150 mayperform e-commerce transactions using, e.g., a web browser, an app, aprogram installed on a personal computer, etc.

FIG. 15 shows an example web page 1500 for an embodiment where thepayment server 140 is integrated with an email server. In this scenario,when the customer logs into their email account, they are logged intothe payment server 140. The customer may be able to send money as afunction of their email account. For example, this may be performedthrough web-based email or an application on the customer device 150. Amember may sign into their email account and be presented with web page1500. As shown in FIG. 15, the web page 1500 may include multiple inputfields 1502-1512. Input fields 1502, 1504, and 1506 allow the member toaccess their email inbox, outbox, and sent messages. Input field 1512allows the member to review their messages. Input fields 1508 and 1510allow the member to send money and get money using the email basedprocess as discussed above. As shown in FIG. 15, the member may beallowed to send and receive money in a manner that is integrated withtheir email account. Further, as the selections are updated, the webbrowser unit 155 may update the web page 1500 to indicate additional, ormore specific, questions that may be associated with the selections.Referring back to FIG. 7, as the customer is signing up with the paymentserver 140, the customer may be also registering for an email account.

In another embodiment the information included in the URL Targeted Tokenand the Email Targeted Token may be in a single token. This token mayinclude additional data including an identifier of an intended use. Thee-commerce system 170 may receive the response email with this token.The e-commerce system 170 may parse the information in the token. Thee-commerce system 170 may be configured to determine, based on theincluded the intended use data the parameters of the action to be taken.In this example a send money email may contain both the data for URL andEmail Targeted Token data and also include information dictating thatthe processing maintains the parameters required by email targetedtokens. The e-commerce system 170 may decode the token using thisintended use data to determine the process and what other data in thetoken is relevant.

As used herein, the term “processor” broadly refers to and is notlimited to a single- or multi-core processor, a special purposeprocessor, a conventional processor, a Graphics Processing Unit (GPU), adigital signal processor (DSP), a plurality of microprocessors, one ormore microprocessors in association with a DSP core, a controller, amicrocontroller, one or more Application Specific Integrated Circuits(ASICs), one or more Field Programmable Gate Array (FPGA) circuits, anyother type of integrated circuit (IC), a system-on-a-chip (SOC), and/ora state machine.

As used to herein, the term “computer-readable medium” broadly refers toand is not limited to a register, a cache memory, a ROM, a semiconductormemory device (such as a D-RAM, S-RAM, or other RAM), a magnetic mediumsuch as a flash memory, a hard disk, a magneto-optical medium, anoptical medium such as a CD-ROM, a DVDs, or Bluray-Disc, or other typeof device for electronic data storage.

Although the methods and features described above with reference toFIGS. 2-15 are described above as performed using the example system 100of FIG. 1, the methods and features described above may be performed,mutatis mutandis, using any appropriate architecture and/or computingenvironment. Although features and elements are described above inparticular combinations, each feature or element can be used alone or inany combination with or without the other features and elements. Forexample, each feature or element as described above with reference toFIGS. 1-15 may be used alone without the other features and elements orin various combinations with or without other features and elements.Sub-elements of the methods and features described above with referenceto FIGS. 1-15 may be performed in any arbitrary order (includingconcurrently), in any combination or sub-combination.

What is claimed is:
 1. A method for peer-to-peer e-commerce transactionbetween a first user and a second user that is facilitated by a paymentserver, the method comprising: receiving, by a receiver, a money requestfrom a first user, wherein the money request identifies a second userfrom which money is requested; determining, by a processor, whether thesecond user is a registered member of the payment server; if the seconduser is not determined to be a registered member, transmitting a signupemail to the second user; if the second user is determined to be aregistered member, transmitting, by a transmitter, a money request emailmessage to the second user, wherein the money request email includes atleast one mailto link associated with the money request from the firstuser and a targeted token, wherein the targeted token includes anembedded identifier of the email address of the first user; receiving,by the receiver, a response email message to the money request emailmessage, wherein the response email message is generated based on the atleast one mailto link selected by the second user and includes thetransmitted token; decoding, by the processor, the transmitted token andconfirming that the embedded identifier of the email address matches theemail address of the targeted token; and performing a Sender PolicyFramework (SPF) and DomainKeys Identified Mail (DKIM) validation of thereceived response email message to validate the transaction.
 2. Themethod of claim 1, further comprising transmitting a URL pay emailmessage to the email address associated with the response email message,if processor determines that the second user is not a member.
 3. Themethod of claim 1, further comprising: processing the peer-to-peere-commerce transaction if the processor determines that the second useris a member; and transmitting, by the transmitter a notification thatthe peer-to-peer ecommerce transaction was successful.
 4. The method ofclaim 1, wherein the peer-to-peer ecommerce transaction is performedthrough a social network website.
 5. The method of claim 1, wherein thepeer-to-peer ecommerce transaction is integrated into an email server.6. The method of claim 1, wherein the money request from the first useridentifies a plurality of users from which money is requested.
 7. Amethod for peer-to-peer e-commerce transaction between a first user anda second user that is facilitated by a payment server, the methodcomprising: receiving, by a receiver, a money request from a first user,wherein the money request identifies a plurality of recipients fromwhich money is requested; determining, by a processor, whether each ofthe plurality of recipients are members; and transmitting, by atransmitter, a plurality of money request email messages to theplurality of recipients, wherein each of the plurality of recipientsthat is determined to be a member receives an email message comprisingan email targeted token, wherein the email targeted token comprises anembedded identifier of the email address of the first user and each ofthe plurality of recipients that is not determined to be a memberreceives an email message comprising an URL signup email.
 8. The methodof claim 7, further comprising receiving, by the receiver, a responseemail message to at least one of the plurality of money request emailmessages, wherein the response email message includes an email targetedtoken; and processing the e-commerce transaction based at least in parton the email targeted token and an email address associated with theresponse email message.
 9. The method of claim 7, further comprisingreceiving, by the receiver, a response message to at least one of theplurality of money request email messages, wherein the response emailmessage includes an URL targeted token; registering at least on userassociated with the response message; and processing the e-commercetransaction based at least in part on the URL targeted token.
 10. Themethod of claim 9, wherein the response message is received via a webpage.
 11. A system for peer-to-peer e-commerce transaction between afirst user and a second user that is facilitated by a payment server,the system comprising: a receiver configured to receive a money requestfrom a first user, wherein the money request identifies a second userfrom which money is requested; a processor configured to determine,whether the second user is a registered member of the payment server; atransmitter configured to transmit if the second user is not determinedto be a registered member, a signup email to the second user and, if thesecond user is determined to be a registered member, a money requestemail message to the second user, wherein the money request emailincludes at least one mailto link associated with the money request fromthe first user and a targeted token, wherein the targeted tokencomprises an embedded identifier of the email address of the first user;the receiver further configured to receive a response email message tothe money request email message, wherein the response email message isgenerated based on the at least one mailto link selected by the seconduser and includes the transmitted token; the processor furtherconfigured to determine whether the second user is a member based on thereceived token and an email address associated with the response emailmessage; the processor further configured to decode the received tokenand confirm that the embedded identifier of the email address matchesthe address of the transmitted token was submitted from the first user;and the processor further configured to perform a Sender PolicyFramework (SPF) and DomainKeys Identified Mail (DKIM) validation of thereceived response email message to validate the transaction.
 12. Thesystem of claim 11, wherein the transmitter is further configured totransmit a URL pay email message to the email address associated withthe response email message, if processor determines that the second useris not a member.
 13. The system of claim 11, further comprising: theprocessor further configured to process the peer-to-peer e-commercetransaction if the processor determines that the second user is amember; and the transmitter further configured to transmit anotification that the peer-to-peer e-commerce transaction wassuccessful.
 14. The system of claim 11, wherein the peer-to-peerecommerce transaction is performed through a social network website. 15.The system of claim 11, wherein the peer-to-peer ecommerce transactionis integrated into an email server.
 16. The system of claim 11, whereinthe money request from the first user identifies a plurality of usersfrom which money is requested.